IP Multimedia (IPMM) services provide a combination of voice, video, messaging, data, etc, within the same session. As the number of basic applications and the media which it is possible to combine increases, the number of services offered to the end users will grow, and the potential for enriching inter-personal communications experience will be improved. This leads to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IMS is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides features to enhance the end-user person-to-person communication experience through the integration and interaction of services. IMS allows enhanced person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP) carried by SIP signalling is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
Within an IMS network, Call Session Control Functions (CSCFs) perform processing and routing of signalling. CSCFs handle session establishment, modification and release of IP multimedia sessions using the SIP/SDP protocol suite. 3GPP TS23.228 describes the logical nodes P-CSCF, I-CSCF, S-CSCF, E-CSCF and BGCF. The S-CSCF conforms to 3GPP TS 24.229 and performs session control services for User Equipments (UEs). It maintains the session state to support the services, and performs the following functions:                it acts as a registrar according to [RFC3261] at registration;        it notifies subscribers about registration changes;        it provides session control for the registered users' sessions;        it handles SIP requests, and either services these internally or forwards them on to a further node; and        it interacts with IMS Application Servers.        
The S-CSCF performs SIP routing according to 3GPP routing procedures.
Most SIP sessions in an IMS, such as calls that are initiated by a UE, are subject to charging by the operator. The IMS architecture provides for two distinct charging models: offline charging, and online charging.
Online charging is based on a so-called pre-paid subscription model. Typically, a subscriber purchases a number of credits from an operator. If a SIP session is initiated by a SIP request sent from the subscriber's UE to the S-CSCF, the S-CSCF contacts an Application Server implementing a Charging Triggering Function (CTF). The CTF Function is described in 3GPP TS 32.260 and 3GPP TS 32.299. It supports charging for users making use of IMS infrastructure and services. The CTF node detects whether the requested session is subject to a charge or not. If the requested session is subject to a charge, the CTF node contacts an Online Charging System (OCS) node in which the subscriber's current credit is stored. If the subscriber's account holds sufficient credit for the SIP request to be granted, the OCS replies accordingly to the CTF, which grants the request. Similarly, if insufficient credit is available, the SIP request may be turned down, or the session may be granted to be established for a limited amount of time.
The CTF and OCS nodes implement the online charging functionalities for the IMS architecture. Communication between the CTF and OCS nodes takes place over the Ro interface described in 3GPP TS32.299, and is governed by the DIAMETER protocol. Specifically, the CTF sends DIAMETER Credit Control Request (CCR) messages, while the OCS replies in DIAMETER Credit Control Answer (CCA) messages. These messages are specified in RFC 4006.
Many developing countries deploying IMS architectures rely exclusively on an online charging infrastructure. Indeed, the technical infrastructure for setting up an online charging system for an IMS architecture is not as complex and costly as the technical infrastructure needed for setting up an offline charging system, in which users are billed retroactively for the services and infrastructure they have used over a period of time.
Problems do however arise when the communication link implementing the Ro interface, which is used to connect the CTF to the OCS, is not reliable. For example, a transaction request may arrive at the CTF node while the OCS is not available, due to the communication link between the CTF and the OCS being down. In case of an error during the handling of a Credit Control Request, the OCS sends a Credit Control Failure Handling Attribute-Value-Pair (AVP), as defined in RFC 4006, to the CTF. The AVP indicates either to CONTINUE with the requested session, to TERMINATE the requested session, or to RETRY and TERMINATE. The default behaviour, which is assumed by the CTF if the OCS sends no reply at all, is TERMINATE. The operator needs to configure the CTF so that is capable of deciding on whether to grant the request, assuming a default behaviour of CONTINUE, or to turn it down, without having access to the credit status of the subscriber who initiates the transactions.
In a conservative approach, the CTF may by default turn the session request down if the OCS is not available. This policy allows the operator to avoid any loss of revenue in case the subscriber's credit balance is indeed not high enough for the transaction to be granted. On the other hand, if the subscriber's credit balance is high enough for the transaction to be granted, the subscriber experiences poor service availability, as the transaction is not granted irrespective of the subscriber's credit balance.
In a less conservative approach, the CTF may grant the session to continue irrespective of the balance of the subscriber's credit if the OCS is not available. This policy leads to a high service availability, but may result in severe losses of revenue for the operator, in case the subscriber's credit balance is not high enough for the transactions to be granted.
According to existing and currently proposed IMS architectures, there is no easy way to configure a CTF node and/or an OCS node so as to address this unsatisfactory behaviour in an IMS online charging model.